Data networks which are coupled to each other frequently require implementation of network address translation (NAT) as the data transfers between networks. Address translation is necessary when all addresses within the coupled networks are not unique, and “Traditional NAT” is an accepted protocol in the art which describes translation of network addresses. The protocol combines and updates earlier protocols and is described by Srisuresh et al. in Request for Comments (RFC) 3022 of the Internet Engineering Task Force (IETF) Network Working Group (January, 2001), which is incorporated herein by reference. Traditional NAT provides a mechanism for transparently connecting a private network having private addresses to an external public network with globally unique registered addresses.
FIG. 1 is a block diagram that schematically illustrates operation of RFC 3022, as is known in the art. A private network 22 is coupled via an address translator 24 to an external public network 26. The coupling from translator 24 to network 26 is via a router 25 in the external network. Address translator 24, which typically comprises software components operating in network 22, translates between internal private addresses of network 22 and unique global addresses suitable for use within network 26. The translation is implemented by translator 24 for data transferring in both directions between the two networks. Traditional NAT translates both Internet Protocol (IP) addresses, and Transmission Control Protocol/User Datagram Protocol (TCP/UDP, referred to collectively as TU) port numbers used by these addresses.
The translation is performed by translator 24 forming a binding between local private addresses and allocated external addresses, the binding being determined when an outgoing data transfer session initiates from a private host. (Data transfer sessions are described in more detail below.) The binding takes the form of a mapping between a first ordered pair (source private IP address, source private TU port) and a second ordered pair (assigned external IP address, assigned external TU port). The first ordered pair is effectively a single extended address which is used for data transfer/routing within network 22. The second pair is effectively a single extended address used for data transfer/routing in network 26. The binding is maintained in a table generated by translator 24, and is used for incoming data transfer to the private host, where the ordered pairs are used to generate the destination addresses.
Using address translation allows private network 22 to continue using its private addresses, while enabling the private network to communicate with an external network, where the private addresses might cause conflicts if not translated.
Srisuresh et al., in RFC 2663 of the IETF Network Working Group (August, 1999), which is incorporated herein by reference, clarifies terms used in NAT, and also enlarges on translation processes. RFC 2663 refers to Basic NAT and Network Address Port Translation (NAPT) protocols, which are incorporated into and superceded by Traditional NAT, described above. In section 2.3 of RFC 2663, a session is defined as the set of traffic that is managed as a unit for translation. Traffic of a session is composed of a sequence of one or more packets, and TCP/UDP sessions are uniquely identified by the ordered tuple of (source IP address, source TCP/UDP port, destination IP address, destination TCP/UDP port).
As explained in section 2.4, servers “listen” for incoming connections, typically on the set of port numbers 0-1023. Typically, clients trying to initiate a connection use a source TU port number in the range 1024-65535. However, these ranges are not universally accepted, and instances where a client initiates a connection using a source port number in the range 0-1023, and/or where servers listen on port numbers in the range 1024-65535, are known.
FIG. 2 is a schematic diagram showing headers of TCP/IP and UDP/IP data packets, as are known in the art. A TCP/IP packet header comprises an IP header 27 and a TCP header 28. The IP header comprises source and destination addresses. The TCP header comprises source and destination ports, as well as other fields including a flags field and a checksum field. The flags field includes ACK, SYN, RST, and FIN bits. These are respectively used as an acknowledgement of receipt of a packet, a synchronization bit used at the initiation of a connection, a reset bit indicating that a receiver should delete the connection without further interaction, and a control bit which indicates that a sender will send no more data. The checksum field is used as a check on correct data receipt, and is a sum evaluating all data of a packet, including the IP and TCP headers.
A UDP/IP packet header comprises the IP header 27 and a UDP header 30. The UDP header comprises source and destination ports, and a checksum field, which is substantially similar to the checksum field of the TCP header.
Sections 2.5 and 2.6 of RFC 2663 respectively describe methods for determining a start and a finish of a specific session of data packet transfer. A TCP session start can be recognized by the presence of the SYN bit and absence of the ACK bit in a received data packet. “The end of a TCP session can be detected when FIN is acknowledged by both halves of the session, or when either half receives a packet with an RST bit in the TCP flags field.” Once these end sections have been detected, RFC 2663 states that, to cover retransmissions due to dropped packets, “. . . a session can be assumed to have been terminated . . . after a period of 4 minutes subsequent to this detection.” RFC 2663 also advocates using garbage collection, as a means of detecting when a TCP connection has terminated without the translation device (translator 24 of FIG. 1) being aware of the termination.
For non-TCP sessions, including UDP sessions, RFC 2663 states “there is no deterministic way of recognizing the start of a UDP based session or any non-TCP session. A heuristic approach would be to assume the first packet with hitherto nonexistent session parameters as constituting the start of a new session . . . . In the case of UDP-based sessions, there is no single way to determine when a session ends.”
RFC 2663 also suggests using timing to terminate sessions, e.g. by assuming that “TCP sessions that have not been used for say, 24 hours, and non-TCP sessions that have not been used for a couple of minutes, are terminated.” Alternatively or additionally, “Another way to handle session terminations is to timestamp entries and keep them as long as possible and retire the longest idle session when it becomes necessary.”
In section 4.1.2 of RFC 2663, the authors state that the Basic NAT and NAPT protocols can be combined so that a pool of external addresses are used in conjunction with port translation.
In order to increase the rate at which communications are transferred between points, it is known in the art to use multiple links in parallel. For example, in place of the point-to-point protocol (PPP) that provides a single link for digital packet communications between computers, the PPP Multilink Protocol may be used. This protocol is described by Sklower et al., in RFC 1990 of the IETF Network Working Group (August, 1996), which is incorporated herein by reference.
FIG. 3 is a block diagram that schematically illustrates operation of RFC 1990, as is known in the art. As for the PPP protocol, two software components, a multilink manager 33 and a multilink manager peer 34, are required. The multilink connection between the two components is set up by manager 33 transmitting a Link Control Protocol (LCP) request to manager peer 34. Once manager peer 34 acknowledges that it is able to accept the multilink connection, transfer of data packets via the parallel multilinks is possible. The transfer occurs by manager 33 fragmenting data into sequenced packets, which are then sent to peer 34, where the sequenced packets are reassembled into the original data. The PPP Multilink Protocol provides a framework for tracking the data fragments sent on each link of the multilink, and for insuring that the fragments are reassembled in their correct order at manager peer 34.
FIG. 4 is a block diagram that schematically illustrates combination of the processes of address translation and multilink transfer, as is known in the art. In transferring data from private network 22 to external network 26, address translation is first performed in translator 24, and then the data is transferred via multilink manager 33, after the latter has set up a multilink with multilink manager peer 34.